This picture represents the core Scrum Framework. Use it whenever you want to give an overview of Scrum. This picture uses the word “refinement” instead of “grooming.”
This picture shows the details of the sprint review activity. It has been updated to use the term “Refined product backlog” instead of “Groomed product backlog”
This picture shows the concept of economically sensible scrum.
This picture shows the the concept of an economic framework.
This picture shows the importance of aligning the perspectives of the development team members in order to have an effective sprint retrospective.
This picture shows the details of the sprint retrospective activity.
This picture shows when the sprint retrospective activity takes place within the context of the Scrum framework.
This picture shows the details of the sprint review activity.
This picture shows when the sprint review activity takes place within the context of the Scrum framework.
This pictures shows the details of the sprint execution activity.
This picture shows when sprint execution occurs within the context of the Scrum framework.
This picture shows a detailed view of a sprint backlog as it might appear during sprint planning.
This picture shows the sprint planning activity.
This picture shows where in the Scrum framework sprint planning occurs.
This picture shows a novel approach for rendering a fixed-date release burn-up chart. Note that the product backlog is inverted.
This picture shows the concept of sprint mapping.
This picture shows the release-planning activity.
This picture shows that release planning is not a one-time, upfront activity. Instead is an activity that occurs every sprint.
This picture shows that a “release” might be made up of multiple sprints, or occur every sprint, or occur multiple times each sprint (continuous deployment).
This picture annotates the envisioning (product planning) activity to show where incremental/provisional funding occurs.
This picture shows the envisioning (product planning) activity.
This picture shows the envisioning is not a one-time activity, but instead an on-going activity. It also shows where the strategic filter is used.
This picture shows that we want to balance the flow of items into the portfolio backlog with the rate at which items are taken out of the portfolio backlog.
This picture shows where the economic filter is applied.
This picture shows the 11 strategies in Agile portfolio planning.
This picture shows the portfolio planning activity.
This picture shows hierarchical Scrum planning beginning at the product level and continuing to the sprint level. It does not show portfolio-level planning or daily planning.
This picture shows how sprint planning results in the creation of a sprint backlog.
This picture illustrates that a release can be composed of the work created during multiple sprints.
This picture shows how releases in the product roadmap are mapped onto the product backlog.
This picture shows a release line through a product backlog.
This picture shows the “planning onion,” the multiple different levels at which planning takes place.
This picture shows how the project or program manager might be involved in handling the coordination on complex development efforts.
This picture shows how the project or program manager might be involved in handling the coordination or logistics for a large development effort involving multiple teams.
This picture shows how teams tend to form communication clusters.
This picture shows an unrealistic scenario where a large number of development teams all have to communicate with one another.
This picture shows how functional managers still manage a community of practice even when their direct reports are assigned out to Scrum development teams.
This pictures shows a metaphor for how managers define the boundaries within which development teams get to self-organize.
This picture shows the team-level part of a release train.
This picture shows the Scrum of Scrums concept.
This picture shows two products that are splitting features across three component teams.
This pictures shows one product backlog with features that are being split across three component teams.
This picture shows the development team's responsibilities within the Scrum framework.
This picture shows that the same person might be the ScrumMaster for more than one Scrum team at the same time.
This picture shows the same person might be the product owner for more than one Scrum team at the same time.
This picture shows the day in the life of a product owner.
This picture shows that the product owner manages the economics at several points in time.
This picture shows how the product owner needs to face two directions simultaneously.
This image shows an example deck of planning poker cards.
This picture shows how planning poker conceptually places items into bins of similar size.
This picture shows that all of the roles on the Scrum team are involved in the product backlog item estimation process.
This picture shows a side-by-side comparison of the various types of estimating that takes place during agile development.
This picture shows how the product backlog can be viewed as a pipeline or requirements.
This pictures illustrates the definition of ready relative to the definition of done.
This picture shows when grooming can take place when applying Scrum.
This pictures shows how the product owner collaborates with many others to perform product backlog grooming.
This picture shows all of the grooming activities applied against a product backlog.
This picture shows the product backlog in the context of the complete Scrum framework.
This picture illustrates how sprints are the backbone or skeleton of the Scrum framework.
This picture shows the sprint retrospective in the context of the complete Scrum framework.
This picture shows the sprint review in the context of the complete Scrum framework.
This picture shows the potentially shippable product increment in the context of the Scrum framework.
This picture illustrates where the daily scrum activity occurs within the context of the Scrum framework.
This pictures show where sprint execution occurs within the context of the Scrum framework.
This picture shows where the sprint planning activity occurs in the context of the Scrum framework.
Use this picture when you want to explain various sprint characteristics: timebox, fixed-length, no gaps, etc.
This picture represents the core Scrum Framework. Use it whenever you want to give an overview of Scrum.
This picture summarizes in mind-map format the Scrum roles, activities, and practices.
This picture provides a basic overview of iteration-based agile development. I typically use it to illustrate basic concepts.
A brief statement of the desired future state that would be achieved by developing and deploying a product. A good vision should be simple to state and provide a coherent direction to the people who are asked to realize it.
A description of the incremental nature of how a product will be built and delivered over time, along with the important factors that drive each individual release. Useful when developing a product that will have more than one release.
Used to represent either the economic filter or the strategic filter.
A backlog composed of products, programs, projects, or high-level epics.
1. The output of release planning. On a fixed-date release, the release plan will specify the range of features available on the fixed future date. On a fixedscope release, the release plan will specify the range of sprints and costs required to deliver the fixed scope. 2. A plan that communicates, to the level of accuracy that is reasonably possible, when the release will be available, what features will be in the release, and how much will it cost.
A condition where the product is not functioning in the intended way.
The technical work that a development team performs in order to complete a product backlog item. Most tasks are defined to be small, representing no more than a few hours to a day or so of work.
1. An item such as a feature, defect, or (occasionally) technical work that is valuable from the product owner’s perspective. 2. An item in the product backlog.
1. A slice of business functionality that is meaningful to a customer or user. 2. Used by some to mean a medium-size user story that can and will be divided into a collection of smaller user stories that together will be implemented to deliver the value of a feature.
A large user story, perhaps a few to many months in size, that can span an entire release or multiple releases. Epics are useful as placeholders for large requirements. Epics are progressively refined into a set of smaller user stories at the appropriate time.
A prioritized inventory of yet-to-be-worked-on product backlog items.
Results that are completed to a high degree of confidence and represent work of good quality that is potentially shippable to end customers at the end of a sprint. Being potentially shippable does not mean the results will actually be delivered to customers. Shipping is a business decision; potentially shippable is a state of confidence.
1. An artifact produced at a sprint-planning meeting and continuously updated during sprint execution that helps a self-organizing team better plan and manage the work necessary to deliver on the sprint goal. 2. A list of the product backlog items pulled into a sprint and an associated plan for how to achieve them—frequently expressed in terms of tasks that are estimated in ideal hours.
1. An artifact produced at a sprint-planning meeting and continuously updated during sprint execution that helps a self-organizing team better plan and manage the work necessary to deliver on the sprint goal. 2. A list of the product backlog items pulled into a sprint and an associated plan for how to achieve them—frequently expressed in terms of tasks that are estimated in ideal hours.
An activity that captures the essence of a potential product and creates a rough plan for the creation of that product. Envisioning begins with the creation of a vision, followed by the creation of a high-level product backlog and frequently a product roadmap.
An activity that captures the essence of a potential product and creates a rough plan for the creation of that product. Envisioning begins with the creation of a vision, followed by the creation of a high-level product backlog and frequently a product roadmap.
Longer-term planning that answers questions like “When will we be done?” or “Which features can I get by the end of the year?” or “How much will this cost?” Release planning must balance customer value and overall quality against the constraints of scope, schedule, and budget.
An activity for determining which products (or projects) to work on, in which order, and for how long. Sometimes referred to as portfolio management.
A rough calculation of the value, number, quantity, or extent of something. In Scrum, we estimate the size of portfolio backlog items, product backlog items, and sprint backlog tasks.
A short-duration, timeboxed iteration. Typically a timebox between one week and a calendar month during which the Scrum team is focused on producing a potentially shippable product increment that meets the Scrum team’s agreed-upon definition of done.
An inspect-and-adapt activity performed at the end of every sprint. The sprint retrospective is a continuous improvement opportunity for a Scrum team to review its process (approaches to performing Scrum) and to identify opportunities to improve it.
An inspect-and-adapt activity that occurs after sprint execution where the Scrum team shows to all interested parties what was accomplished during the sprint. The sprint review gives everyone with input in the product development effort an opportunity to inspect what has been built so far and adapt what will be built next.
The period of time during which the development team performs the tasks necessary to complete the features selected during sprint planning.